Mobile terminals may be used to play video, such as mobile phones, under various network environments including Second Generation mobile network (2G), Third Generation mobile network (3G), Fourth Generation mobile network (4G), or Wireless Fidelity network (WIFI). Due to complexity and changing network state, the stability of played content is relatively low. In an application scenario in which a mobile terminal device shares recorded content in real time, the live content on the mobile terminal device has time sensitivity. If the recorded content is attractive, and draws a lot of attention from a user terminal, it needs to be ensured that the played content does not lag, so as to provide smooth and stable live content to the user terminal, thereby improving the user experience. In a mobile network environment, the state of network is restricted by the distance to the geographic base station to a great extent, and is also affected by the population density. Thus, an original 4G mobile network may degrade to a 3G mobile network, or even degrade to a 2G mobile network. In this way, the decrease of the transmission speed of the mobile network greatly restricts the uploading of the live content. Similarly, in a WIFI wireless network environment, coverage of WIFI hotspots often is incomplete. Because the user terminal is mobile, the strength of WIFI signal received in different locations is also different, and this also affects the stability of the uploading of the live content of the mobile terminal.
Currently, there are three solutions of real-time capturing, encoding, and uploading for most of mobile applications. First, at the beginning of encoding and uploading the live content, a lowest definition and a lowest bitrate are matched in priority. But, according to the encoding and uploading method, the play quality during a live show process remains unchanged, and the user terminals have a relatively poor experience; and optimal picture quality cannot be provided even when the state of network becomes better, and dynamic adjustment cannot be performed when the state of network becomes poor.
Second, when a network jitter becomes poor and cannot meet an uploading speed required by a current bitrate, some coded data frames of the video is dropped to reduce the data volume of the bitrate in an alternative way, so as to perform live uploading. But the disadvantages of the solution are the loss of original compressed image content, the decrease of the frame rate, the decrease of fluency of the video, and the reduction of the amount of content information. Further, the data of a group of images (GOP for short) of key frames of the video needs to be synchronized. It is possible that, with 1 to 2 seconds of image data loss, if not processed properly, the lost data may cause a decoding failure on a playing client-end and abnormal images. It may also cause image jump on the playing client-end, leading to experience of discontinuity, as frequent frame dropping processing can cause the lagging and jumping feeling.
Third, in the process of live uploading the recorded content, the encoder is reconfigured, and the audio and video bitrate is reconfigured according to the current network speed, and live uploading is passively restarted, which can cause the extra process from interruption of the live uploading to re-initialization, consuming addition time and affecting the playing client-end with lag buffering and waiting. If the live uploading establishes multi-layer and complex links, the speed of recovering on the playing client-end is very slow and, in this way, it is inevitable to lose users. If the number of users watching the recorded content is very large, such interruption and recovery are also great challenges to the stability and bandwidth adjustment of servers.
Thus, according to the present disclosure, such existing technical solutions have the following advantages: first, controlling the overall quality by the low bitrate first method cannot flexibly adapted anytime and anywhere; second, even a dynamic control method is used, the method is excessively simple and crude, and can cost relatively large amount of user experience; and third, incurrence of extra cost of operation and overhead of machine scheduling, increasing the probability of accident, and lacking security and robustness.